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Abstract - This report identifies an 802. 16e system profile 
that is applicable to a lunar surface wireless network, and 
specifically for meeting extra-vehicular activity (EVA) data 
flow requirements. EVA suit communication needs are 
addressed. Design-driving operational scenarios are 
considered. These scenarios are then used to identify a 
configuration of the 802.16e system (system profile) that 
meets EVA requirements, but also aim to make the radio 
realizable within EVA constraints. Limitations of this 
system configuration are highlighted. An overview and 
development status is presented by Toyon Research 
Corporation concerning the development of an 802.16e 
compatible modem under NASA’s Small Business 
Innovative Research (SBIR) Program. This modem is 
based on the recommended system profile developed as part 
of this report. Last, a path forward is outlined that presents 
an evolvable solution for the EVA radio system and lunar 
surface radio networks. This solution is based on a custom 
link layer, and 802.16e compliant physical layer compliant 
to the identified system profile, and a later progression to a 
fully interoperable 802. 16e system. 


I. INTRODUCTION 

In 2004, the Bush administration unveiled the United 
State’s Vision for Space Exploration (VSE) [1]. This 
included the very ambitious goal of creating and 
sustaining a human presence on the Moon and Mars. 
NASA’s plan for achieving the VSE was first introduced 
in the Exploration Systems Architecture Study (ESAS) 
released in November of 2005 [2]. Since this time, 
NASA has embarked upon a number of agency-wide, 
inter- center studies to further develop and refine the 
exploration architecture as presented in the ESAS final 
report. 


NASA’s Lunar Architecture Team produced a report that 
identifies the 802. 16e standard as the wireless technology 
of choice for lunar surface-to-surface radio 
communications [3]. The study identifies the 
architecture and required data capacities of a surface 
802. 16e system without defining a specific configuration 
or “system profile”, as appropriate for an architecture 
study. 

Under Constellation Systems, the EVA Exploration 
Technology Development Program (EVA ETDP) has 
initiated an effort to evaluate configurations of this 
802. 16e standard, as well as identify the capabilities it 
lacks and the innovations that will be required by NASA. 

II. OBJECTIVES 

There are three objectives for this study. First, a high 
level system profile must be identified that supports the 
requirements for the EVA system. “System profile”, 
with regards to the IEEE 802.16 standard and 
amendments, refers to a particular configuration of the 
parameters within the standard that form a unique 
instantiation of a system targeted for a particular market. 
This allows chip manufactures and system integrators to 
develop and build 802.16 systems that are interoperable 
for specific deployments. A system profile, at a very 
high level, defines these characteristics: 

• radio network topology 

• duplex scheme 

• power class 

• radio frequency 

• signal bandwidth 


NASA/TM— 2009-2 1 5624 


1 



• slot time 


The second objective is to evaluate the feasibility of 
developing a modem based on the identified system 
profile that will have a path to space flight, as well as 
minimize size, weight, and power requirements. 

The last objective is to identify or develop a scheme in 
which point-to-point communications between EVA 
astronauts can be accommodated. The 802.16 standard 
describes a mesh mode of operation; however this is an 
optional mode of operation and has not been 
implemented in commercial equipment. It is highly 
desirable, although not required, to utilize as many 
common hardware/firmware/software components for 
both modes of operation as possible. 

III. 802.16e SYSTEM PROFILE IDENTIFICATION 
METHOD 

The following is an outline of the method used to satisfy 
the first objective of this study: 

1. Identify the EVA system communications 
requirements. 

2. Identify and characterize the data flows involved 
with EVA operations. 

3. Create a subset of communication operational 
scenarios that define how these requirements are 
realized. 

4. Determine the data capacity of all configurations 
(system profiles) of an 802. 16e system via 
simulation. 

5. Identify an 802. 16e system profile that meets the 
referenced or assumed EVA system requirements, if 
one exists. 


IV. EVA COMMUNICATION NEEDS 

Communication requirements for EVA lunar surface 
operations are not baselined and require further 
maturation. However, from a functional perspective 
there are several needs that are envisioned based on draft 
operational concepts such as: 

• Direct suit-to-suit (point-to-point) 

communications between two crew radios 
without reliance on external assets. 

• Communications between two teams of two 
crew members through a relay. 

• Communications with other Constellation assets 
such as a habitat, lander, a rover, or a lunar 
network infrastructure (up to 4 assets during 


sortie missions, and up to 6 assets during 
outpost missions). 

• Video for situational awareness. 

• High resolution video and imagery for 
engineering and scientific analysis. 

These needs are summarized in Table 1. These 
requirements form the basis for data flow analysis and 
operational scenario development. 

TABLE 1 - EVA SUMMARY COMMUNCATION NEEDS 

EVA Communication Needs 

Communicate with 4 elements during sortie missions. 
Communicate with 6 elements during Lunar Outpost mission. 
Provide real-time, standard definition video. 

Process telemetry from other systems. 

Provide capability to transmit HDTV 
Direct suit-to-suit intercom system 


Table 1 summarizes both draft and baseline requirements 
appertaining to EVA communications. These 
requirements form the basis for data flow analysis and 
operational scenario development. 

V. EVA DATA FLOWS 

For the purposes of this study, some basic assumptions 
are made to estimate the data capacity requirements of a 
potential 802. 16e system profile for EVA. 

First, all information is conveyed via UDP/IPv6 packets 
and incur the corresponding overhead. IP header 
compression is not assumed. It has also been assumed 
that this information is optimally packed into the UDP 
datagrams to the extent that it may be without interfering 
with the data production rate. As a consequence, voice 
suffers the highest overhead/data ratio. 

Second, for this study constant information generation 
rates are assumed for all data flows. This is generally 
applicable for peak traffic loading estimation, but is 
generally not the method utilized for characterizing 
traffic loads in packet-based, statistically multiplexed 
networks. However, a statistical traffic analysis has not 
been performed for all data flows. Therefore, stochastic 
models of each data flow do not yet exist. The results of 
this report, in effect, apply to worst-case traffic loading 
situation. 
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TABLE 2 - DATA FLOW SUMMARY 


Data Flow 

Data Rate 

BioMed and Suit Data 

2.3 kbps 

Nominal Voice (G.729) 

61.6 kbps 

Standard Definition Video (NTSC Quality) 

1.390 Mbps 

High Definition Video 

(HDTV: 720p/ 60 Hz, 120:1 compression 

ratio) 

7.411 Mbps 


Table 2 displays the data rates developed in this study, 
including overhead, for the data flows of interest. This 
will be used, together with the operational scenarios, to 
estimate peak aggregate traffic data rate requirements. 

Note that a Caution and Warning (C&W) data flow is not 
included in Table 2. Although the C&W data flow is of 
high priority, it has a very low data rate requirement and 
may not be implemented as a network traffic data flow 
(IP-based). For these reasons, it will have little effect on 
the peak aggregate data rate requirements. 

VI. OPERATIONAL SCENARIOS AND DESIGN 
DRIVERS 

It is necessary to first identify the data flow requirements 
in order to identify an applicable 802. 16e profile as a 
solution for the radio network on the lunar surface. 


A more comprehensive report in this area can be found in 
the ETDP-EVA-PCAI-001 1 - EVA/ETDP 802. 16e Lunar 
System Profile Report [4], in which a number of 
scenarios are presented that help to identify the 
aggregated data needs of EVA operations. 

Two important assumptions need to be noted regarding 
this analysis. First, the HDTV “Draft” requirement is not 
a design driver for this exercise. However, it will be 
shown that an HDTV data flow can be supported given 
the 802. 16e profile selected. 

Second, and most importantly, the optional mesh 
capability described by the 802. 16e standard is not 
considered a viable option for this application. No 
current commercial implementations of the optional 
mesh portions of the standard have been identified. 
Furthermore, the active 802. 16j Relay Task Group [5] is 
working on the completion of a final draft amendment to 
the current standard which adds relay capability in the 
form of small, deployable repeaters. However, in this 
architecture a base station remains a single coordinator of 
all radio resources, and the repeaters are deployed to 
extend the range of the base station’s cell. Therefore, 
only the Point-to-Multipoint (PMP), cellular 802. 16e 
architectures are considered. 

In the 802. 16e network architecture for the lunar surface, 
the base station (e.g Altair, Rover, and/or Habitat) would 
be the router and arbitrator of all data and radio 
resources, similar to cellular phone networks. Figure 1 
illustrates the possible simultaneous data flows that 
would need to be supported based on the most data 
intensive scenario identified in [4] for a PMP 
architecture, in which the lunar Habitat provides an 
802. 16e base station. 
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Hab + 4 EVAs: PMP Architecture 
(Nominal Ops) 



Data Flows Key 

^ BioMed and Suit Data 
Nominal Voice (G.729) 

^ Standard Def. Video 
(NTSC Quality) 


FIGURE 1 - DESIGN DRIVING SCENARIO 


This configuration makes the assumption that all voice 
data flows are simultaneously active at any one time. It 
is not unrealistic for biomed, telemetry, and operational 
video to be active simultaneously. These data flows are 
the major design drivers for the radio network due to 
their bandwidth consumption. 

802. 16e also allows for the use of multicast data flows 
within the architecture. Therefore, individual EVA suits 
may multicast their biomed, suit telemetry, voice, and 
operational video to other suits without the need to set up 
individual connections to each other. 

Although the scenario depicted in Figure 1 may not be a 
typical scenario, the lunar surface radio network needs to 
provide enough capacity to support these data demands. 
It is important to note, again, that the EVA astronauts 
must route all information through the base station 
(Habitat, Rover, or Lunar Communications Terminal 
(LCT)) in an 802. 16e PMP system. 


The aggregate data flow that this system profile would 
need to support is presented in Table 3. 


TABLE 3 - AGGREGATE DATA NEEDS FOR DESIGN 
DRIVING SCENARIO 


Flows 

Count 

Total (Mbps) 

BioMed and Suit Telemetry 

16 

0.037 

Nominal Voice 

20 

1.232 

Standard Definition Video 

4 

5.560 


TOTAL: 6.829 Mbps 


The 802. 16e high level system profile is selected to 
support these data flow needs. However, nominal 
operations with only 2 EVAs will only need to support 
the data flows identified in Figure 2. 
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Altair + 2 EVAs: PMP Architecture 
(Nominal Ops) 



Data Flows Key 

** BioMed and Suit Data 
Nominal Voice (G.729) 

^ Standard Def. Video 
(NTSC Quality) 

FIGURE 2 - TYPICAL EVA SCENARIO 


The aggregate capacity of this scenario is presented in 
Table 4. 


TABLE 4 - AGGREGATE DATA FLOW NEEDS FOR 
TYPICAL SCENARIO 


Flows 

Count 

Total (Mbps) 

BioMed and Suit Telemetry 

8 

0.018 

Nominal Voice 

10 

0.616 

Standard Definition Video 

2 

2.780 


TOTAL: 3.414 MBPS 

In selecting an appropriate 802. 16e system profile every 
effort is made to reduce the complexity of both the EVA 
RF front end and baseband implementation. This will 
ultimately lead to reduced size, weight, and power values 
for the EVA radio. 


VII. 802.16e SYSTEM PROFILE FOR EVA 

The recommendation of this study is to adopt the 802. 16e 
PMP architecture for the lunar surface and potential EVA 
communications when adequate infrastructure has been 
deployed. The PMP operations would be ideal for 
nominal operations in that it is a full reservation-based 
system (supporting multiple QoS levels), as well as 
providing power and timing control of the in network 
radios. 

Section XIII of this report introduces an intermediate step 
toward full PMP deployment of an 802. 16e system. This 
approach utilizes a custom medium access control 
(MAC) implementation being developed specifically to 
support point-to-point communications while 
simultaneously mapping network traffic priorities 
defined by Constellation Systems to those supported by 
the link layer. The approach also makes use of a modem 
being developed to support the recommendations of this 
study, thereby minimizing the difficulty in transitioning 
to a fully deployed 802. 16e lunar communications 
system. 
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The lunar surface EVA suit communications system must 
make every effort to reduce the size, weight, and power 
requirements due to the limited resources available. A 
time-division duplex (TDD) scheme allows the uplink 
and downlink to be tuned to the same frequency, 
reducing the requirements of capabilities of the hardware 
in the RF front end. Consumer equipment manufacturers 
and service providers, as well as the standard itself, make 
use of the TDD option for small, power restricted devices 
such as smart phones and gaming devices. 

Human radiation limits restrict the power output of the 
EVA radio to 1 Watt effective isotropic radiated power 
(EIRP) [6]. Therefore, the system profile will have a 
power limitation of 1 Watt EIRP for the EVA radio 
system. 

S-Band has been identified as a potential frequency band 
that will be supported for lunar surface contingency 
communications [7]. The surface to Lunar Relay Satellite 
(LRS) link has been identified as operating in the 2.2 
GHz range, using TDRSS compatible signaling and 
spectrum allocations. 

Currently, the only profile that exists for 802. 16e 
operations in an unlicensed band is at 5.8 GHz (upper 
Unlicensed National Information Infrastructure band). 
However, the deployments in this band are primarily 
fixed, point-to-point microwave systems. Other bands 
available for 802. 16e systems are licensed bands. 

In the US, early deployments of 802. 16e systems will 
likely by in the 2.5 GHz range. However this is licensed 
spectrum owned by Sprint Nextel and Clearwire. It is the 
recommendation of this study that Constellation Systems 
consider the use of an 802. 16e system on the lunar 
surface in the 2.4 GHz unlicensed band. This will 
promote interaction with international partners, as well as 
provide the possibility of a single radio platform that has 
the capability to communicate with the LRSs, the lunar 
surface wide area network, an directly in a point-to-point 
fashion between EVAs. In addition, ground development 
and testing will have the additional benefit of the 
extensive set of test equipment available specifically for 
this band. 

A caveat of this approach is that terrestrial systems 
operating in the 2.4 GHz unlicensed band are limited to 
100 mW of maximum output power. NASA would 
likely have to make the necessary proposals at the World 
Radio Conference in 2011 (WRC-2011) or obtain 
experimental licenses from the National 
Telecommunications and Information Administration 


(NTIA) to operate at higher powers in this band - even 
on the lunar surface. 

Slot time, in general, should be chosen to minimize the 
overhead of the highest priority traffic flowing over the 
system. In the case of EVA, operational voice is 
considered a mission critical data flow (i.e. The EVA 
will terminate if at least voice communications between 
crew, or with the Lander, Habitat, or Mission Control are 
not maintained). For this study, it has been assumed that 
a G.729 codec with a 10 msec frame is utilized for voice 
data flows. Therefore, a slot time of 10 msec has been 
chosen for the 802. 16e profile. 

The signal bandwidth is chosen to provide the 6.829 
Mbps maximum aggregate data rate requirement as 
identified by the design driving scenario (modified for an 
802. 16e PMP system), coupled with the previously 
identified 10 msec frame time. Additionally, it is 
desirable to minimize the signal bandwidth of the system 
for multiple reasons, not the least of which is minimizing 
the RF front-end noise and maximizing the possible 
communications range. 


TABLE 5 - 802.16E AGGREGATE DATA CAPACITY (IN 
MBPS) FOR THE 5 MHZ SIGNAL BANDWIDTH, 10 
MSEC TIME SLOT CONFIGURATION 



5 MHz, 10 msec Slot Time 

0.25 

0.5 

0.75 

BP SKY* 

1.14 

0.67 

0.21 

OPSKVz 

2.38 

1.42 

0.46 

QPSK % 

3.63 

2.16 

0.64 

16 -QAM Y* 

4.88 

2.9 

0.88 

16-QAM % 

7.44 

4.4 

1.44 

64-QAM 2/3 

9.84 

5.84 

1.84 

64-QAM % 

11.04 

6.56 

2.08 


Table 5 displays the aggregate data capacity (in Mbps) 
vs. modulation/code (left column) rate vs. 
uplink/downlink ratios (ratios at the top of each column). 
For a signal bandwidth of 5 MHz and a 10 msec slot 
time, the simulation results show that a data capacity of 
1 1.04 Mbps can be achieved with a 64-QAM modulation 
at a 3/4 ? s code rate. 

In this study, the 802. 16e system profile is being 
identified to support the driving design scenario in Figure 
1. This scenario requires an aggregate capacity of 6.892 
Mbps. However, nominal operations require an 
aggregate capacity of 3.414 Mbps. The aggregate 
capacity of the system profile chosen is 11.04 Mbps with 
the highest modulation/code rate pair. Therefore, the 
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system can support approximately 7.62 Mbps of excess 
capacity during nominal operations. Within this excess 
capacity, it is possible to transfer one HDTV data flow 
with the configuration shown in Table 2. However, the 
signal-to-noise ratio would need to be sufficiently high, 
with the likely possibility of requiring higher-gain 
antennas on the base station to specifically support these 
transfers. Other data flows (especially critical data 
flows) would operate at the lower modulation/code rate 
pairs in nominal operations. 

A note should be made regarding the uplink/downlink 
ratio in the simulations performed for this study. The 
uplink is defined as the direction from the base station to 
the EVA system, whereas the downlink is the reverse 
link from the EVA system to the base station. The 
simulations were performed primarily with the concern 
of retrieving data from EVA mobile units in the field. 
This is a significant paradigm shift from Internet and 3G- 
type traffic, in which the majority of data is retrieved 
from a server residing on the Internet or the service 
provider networks. 

However, due to the fact that 802. 16e systems are 
reservation-based and scalable in terms of instantaneous 
bandwidth requirements, the maximum data capacity 
identified by the simulations will scale well in both 
capacity and asymmetry of data flows. 

It was identified in our simulations that in most cases at 
least a 25% uplink/downlink ratio of the TDD frame was 
necessary to move the control signaling necessary for the 
802. 16e cell, however this was not fully investigated. A 
more efficient (potentially automated) scaling of the 
uplink/downlink by an 802. 16e base station would better 
utilize the existing bandwidth. 

This selection corresponds to a sampling frequency of 
5.6 MHz, a Fast-Fourier Transform (FFT) size of 512 
points, 8 sub-channels, a sub-carrier frequency spacing of 
10.94 kHz, and a useful symbol time of 91.4 
microseconds (minimal guard time) [8]. 

Table 6 summarizes the high level system profile 
parameter selections. 


TABLE 6: RECOMMENDED HIGH-LEVEL 802.16E 
SYSTEM PROFILE 


Parameter 

Selection 

Radio Network Topology 

Point -t o-M u It i point 

Duplex Scheme 

Time Division Duplex 

Power Class 

1 Watt EIRP 

Radio Frequency 

2.4 GHz ISM Band 

Signal Bandwidth 

5 MHz 

Slot Time 

10 msec 


VIII. A NOTE ON DATA RATE VS. RANGE 

Surface-to-surface communications, primarily due to the 
varying terrain and multipath fading mechanisms, suffer 
from deep fades and potential inter-symbol interference 
(ISI). It is not uncommon to see 10-20 dB of link margin 
(with free space path loss assumed) accounted for to help 
overcome losses due to partial blockages from terrain 
entering into the first Freznel zone [9]. 

Unfortunately, multipath fading and ISI are not 
phenomena that can be compensated for simply by 
increasing the transmit power. At this point in time, 
NASA does not have enough lunar site- specific 
information to determine what mechanisms will be 
needed to combat multipath effects for lunar surface 
missions. However, 802.16 and 802. 16e systems have 
incorporated many mechanisms to overcome multipath 
fading effects, including: selectable symbol prefix 

extensions, diversity techniques, multiple signal 
bandwidth selections, variable modulation/code rate 
pairs, automatic repeat-request (ARQ) and hybrid ARQ 
schemes, etc. 

This study chooses only to address the multipath fading 
issue indirectly, being that 802. 16e has these mechanisms 
available. However, path loss needs to be directly 
considered when approximating data rate vs. range for 
site- specific areas. 

NASA has performed a study utilizing a modified 
version of a very familiar terrestrial irregular terrain 
model [10], adapted specifically for the lunar surface. 
This study showed excessive path losses, exceeding at 
times, d 4 path loss at S-band frequencies for realistic 
antenna heights on the lunar surface communicating over 
varied terrain. Therefore, for this study a 20 dB link 
margin policy is enforced. 

Combining this link margin policy with realistic 
assumptions concerning EVA and Altair antenna gains (0 
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dB and 2 dB, respectively), modulation/code rate pair 
required Eb/No values, and maximum transmit powers, 
data rate vs. range estimates for the identified 802. 16e 
system are given in Table 7. 


TABLE 7: DATA RATE VS. PATH LOSS AND RANGE 


Aggregate Data Rate 
(Mbps) 

Path Loss (dB) 

Range (km) 

11.04 

-97.2 

0.7 

9.84 

-98.9 

0.9 

7.44 

-102.9 

1.4 

4.88 

-107.3 

2.3 

3.63 

-109.3 

2.9 

2.38 

-112.6 

4.2 


This table represents the ideal range using a free space 
path loss model and a 20 dB link budget policy. 
However, the effects of irregular terrain will dramatically 
affect communication coverage at S-band frequencies. 


The plot in Figure 3 is the result of a path loss analysis 
created with the method described in [10] for an 
analogue lunar site. The elevation information for this 
site is a modified version of Meteor Crater’s profile, 
appropriate for a sphere the size of the moon. The 
parameters of the model are set so that composition of 
the terrain approximated the lunar regolith composition 
and atmospheric effects are removed. The rings on this 
plot are increments of 1 km, concentric on the 
transmitter. The transmitter is approximately 1/3 of a 
kilometer northwest of the crater. The applicable range 
of communications, according to the data above, is likely 
out to the areas in yellow. However, note that the 1 1.04 
Mbps is only achieved out to 500-700 meters from the 
transmitter, which is assumed to be approximately the 
height of Altair's antenna. Note also the shadowing 
effects of the crater’s rim. All communications from the 
lander behind the crater (to the southeast) are shadowed 
or blocked. This part of the study clearly illustrates the 
effect of the lunar surface regolith composition and its 
irregular terrain. 



FIGURE 3 - ANALOGUE LUNAR SURFACE PATH LOSS 
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IX. 


MODEM DEVELOPMENT 

Under a 2007 Phase II Small Business, Innovative 
Research (SBIR) contract, Toyon Corporation is 
developing a small form factor, software defined modem 
deriving requirements from the system profile presented 
in this report. This modem is being considered as part of 
a technology development effort to prototype the 
approaches recommended in this study. Section X 
through Section XII of this report describe the status of 
the work being done under this SBIR contract. 


X. MODEM DEVELOPMENT: IEEE 802.16e 

WAVEFORM AND SIGNAL MODEL 

The IEEE 802.16-2004 specification includes both 
narrowband single carrier as well as wideband waveform 
profiles, which employ orthogonal frequency division 
multiplexing (OFDM) [11]. The IEEE 802. 16e 

Amendment expands on the original 2004 specification 
by incorporating scalable OFDM (SOFDM) [12]. 
SOFDM is targeted towards the use of mobile 
applications whereby a base station may need to support 
a wide range of mobile users. 


As such, the profile supports a range of channel 
bandwidths from 1 .25 MHz to 20 MHz, all with adaptive 
modulation. Such scalability is designed to allow the 
wireless system engineer to employ hardware and 
software reuse in the design process. 

The overall transmitter and receiver structure for the 
target implementation of the IEEE 802. 16e waveform is 
shown in Figure 4. For the purposes of this paper the 
primary concern is with the initial acquisition of the 
OFDM packet as well as associated parameters, 
including the frequency offset. Assisting in this process, 
the 802. 16e specification uses an innovative preamble 
structure. In addition to the preamble structure itself, the 
cyclic-prefix structure common to OFDM signals (which 
is also found in the IEEE 802.16 waveform) can be 
exploited. From Figure 4 it can be seen that the model is 
comparable to a classic OFDM waveform. At the 
receiver, a timing estimate is first performed to 
synchronize to the start of the OFDM packet, which has a 
preamble as the first OFDM symbol. This is then 
followed by both fractional as well as integer frequency 
offset estimation procedures. 


Modulated 



FIGURE 4 - BASIC 802.16e SIGNAL MODEL AND RECEIVER PROCESSING FOR OFDMA PROFILES 
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FIGURE 5 - OFDM SYMBOL STRUCTURE IN THE 
PREAMBLE 

Figure 5 illustrates the preamble structure found in the 
IEEE 802. 16e specification. The number of symbols in 
the preamble sequence is given by the equation 

_ (A r j7j? r — 2N G ) 


where ^fft is the number of points in the OFDM profile 
and A r c is the number of points in the guard band, which 
is found on both the left and right sides of the preamble 
sequence. This guard band length varies according to the 
FFT size. With 1024, 512, and 128 FFT points, the guard 
band lengths are 86, 42, and 10 samples, respectively. 
Note that the preamble sequence itself is modulated using 
a boosted binary phase shift keying (BPSK) encoding. 

The most important feature of the preamble sequence is 
that only every third symbol takes on a BPSK symbol 
value, with all other values being equal to zero. This 
results in a cyclostationary structure in the time domain. 
In particular, the first and second half of symbols, that 
are output from the IFFT, are reverse conjugate pairs. As 
can be seen in the section on time estimation, this 
structure is pivotal in determining the receive signal time 
offset. 


IEEE 802. 16e signals are subject to the same channel 
impairments found with all wideband signals, including 
multipath and noise. As the primary area of discussion in 
this paper will be on timing and frequency offset 
estimation, only those channel effects that impair the 
estimates of those parameters are of concern. In 
particular, this will be carrier offset mismatch between 
the transmitter and receiver, as well as due to Doppler, 
arbitrary phase rotation, and time offset. The resulting 
received signal is given by 

r[n] = + v [ n ] 


£ - F ° L 

where / Ls is the normalized frequency offset, & 

is an arbitrary phase offset, is the OFDM signal, and 


v[n] 

is additive white Gaussian noise. For the frequency 
offset, F a is the sampling frequency and Fo is the 
frequency offset due to RF carrier mismatch and 
Doppler. Note that in our receive signal model, and 
associated simulations, an oversampling rate whereby 
?iO = m w ith 0 being the oversampling rate and n the 
symbol rate is used. 


XI. MODEM DEVELOPMENT: TIME AND 

FRACTIONAL FREQUENCY OFFSET ESTIMATION 

Work presented in this paper is focused on initial 
acquisition of the IEEE 802.16 signal. A couple of key 
features of the OFDM preamble sequence are employed. 
The first is the fact that with only every third frequency 
sample of the IFFT input being populated, the resulting 
time sequence has a reverse conjugate output. Thus, in 
order to correlate with the preamble, one may simply 
take the first and second half and multiply the reverse 
sequences, which are already conjugate pairs. This 
procedure is shown in Figure 6. 



FIGURE 6 - ILLUSTRATION OF CONJUGATE 
SYMBOL PAIRS THAT RESULT FROM IFFT 
OPERATION 

The second key feature of the IEEE 802. 16e signal is the 
fact there is a cyclic prefix that is appended to the 
beginning of the OFDM symbol. This is nominally l/8 th 
of the OFDM symbol size, but can be varied in several 
fractional multiples. The cyclic prefix (CP) structure is 
shown in Figure 7 is nominally used to remove ISI in the 
receive waveform. Here we exploit the CP in order to 
have a set of symbol pairs that are separated in time, and 
thus prone to a common phase rotation [11]. 
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FIGURE 7 - TAIL OF DATA PAYLOAD IS INSERTED 
AT THE BEGINNING OF THE TIME SEQUENCE 

The most important signal estimate for the entire OFDM 
receive chain is the time offset, which provides a start of 
packet estimate. The time estimate procedure focuses on 
finding the maximum of the equation [13] 



Time index 

FIGURE 8 - TIME OFFSET ESTIMATION WITH SNR 
OF 0 DB AND N FF t=128 


r[n] = 

where 




- V FFT 

2 

p[n] = r[? i -F k]r[? i -f N FFT — k] 

k= l 

and 

jh 'F FT 

2 j \fft 

q\ri\ = y |r[?i + k]r[n -f k]\ -f "S' |r[n -f k]r[n -f k]\ 


We note that these computations are performed at the 
oversampled data rate in order to obtain fine timing 
resolution. Alternatively, the procedure can be conducted 
on data at the symbol rate and a fine time resolution 
performed in frequency domain. However, our 
simulation results have not shown promising results for 
this procedure. Thus, while more complex in its 
implementation, an oversampling approach is likely to 
lead to more reliable performance. 

Algorithm performance on simulated data is shown in 
Figure 8. Regions of noise as well as OFDM symbol 
period itself are shown in the figure. Note that while 
noise is sufficiently low and unlikely to lead to a false 
detection, several false peaks in the sequence are 
observed. Thus, it is likely that an absolute threshold 
cannot be used and therefore will require implementing a 
windowing search procedure in the final hardware 
implementation. 


Once a time offset, T , has been obtained we now have 
knowledge of the time alignment for the first OFDM 
symbol, which is the preamable, along with the CP. This 
procedure begins by downsampling to the symbol rate. 

z[?n] = T t] 

with the index of m beginning at the first time index of 
the CP of the OFDM symbol. We can now form the 
angle estimate as 

JV rp 

£ = ,,, ln(iVr + 

" i Cp m=l 

where is the length of the CP. 

Simulation results for the frequency offset algorithm are 
shown in Figure 9. The actual frequency offset was five 
thousand Hertz. At each signal-to-noise ratio (SNR) one 
hundred Monte Carlo runs were performed. The figure 
shows the mean and standard deviation for the resulting 
frequency offset estimate. As can be seen from the 
figure, the algorithm achieves excellent performance and 
under most circumstances is able to estimate the 
frequency offset to within only a few tens of Hertz. 
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FIGURE 9 - MEAN AND STANDARD DEVIATION OF 
FRACTIONAL FREQUENCY OFFSET ESTIMATION 
WITH Nfft=128 

The fractional frequency offset estimation procedure is 
not able to estimate integer multiples of the offset to 
within the number of OFDM carriers times their 
frequency spacing. For instance, with fft = 1-8 the 
maximum offset cannot be greater than about ten kHz. In 
the event the carrier offset is greater than this amount, an 
integer estimate will need to be performed in frequency 
after the FFT. The downside of this operation is that the 
preamble sequence must be known. This limits the 
flexibility of the hardware design as both the timing and 
fractional frequency offset estimates can be performed in 
a blind manner. The advantage of blind estimation is that 
instead of having to precode the preamble in the receiver 
design it can instead be used as a received data sequence. 
In this case the preamble can indicate useful features, 
such as the base station ID. This can of course be 
determined through a search procedure over the possible 
preamble sequences, but this is computationally 
intensive, and hence undesirable from the perspective of 
a hardware designer. 

XII. MODEM DEVELOPMENT: HARDWARE 

ARCHITECTURE 

Whereas terrestrial applications can call upon the large 
number of IEEE 802.16 baseband and MAC chipsets, 
these integrated circuits are not suitable for the harsh 
environment of space. In particular, without heavy 
shielding they are prone to failure due to the wide 
temperature ranges and radiation found in the lunar 
environment. Short of catastrophic failure, such devices 
are prone to disruption of normal operation due to single 
event upsets (SEUs). For these reasons there are many 


safeguards and special engineering design considerations 
that are used for the development of wireless transceivers 
to be used in space applications. 

Toyon’s general approach for the development of an 
IEEE 802.16 wireless transceiver to be used in lunar 
exploration is to leverage a system on a chip (SoC) 
design, made possible via a field programmable gate 
array (FPGA). We note that there are several vendors 
who make aerospace-grade FPGAs. For this development 
Xilinx solutions are of interest. Currently available 
Virtex-4QV parts can meet extended temperature ranges 
and accept over 200 krad of total ionizing dose (TID). 
Triple mode redundancy (TMR) can be used during the 
hardware design flow to mitigate SEU. We note that 
future aerospace- grade Virtex-5 devices will incorporate 
TMR-like functionality within the hardware itself, thus 
greatly easing the engineering effort needed to mitigate 
latchups and bit errors. 

Thus, the EXP connector carries only digital data. One 
major advantage of this general design approach is that 
RF front-ends and FPGA base boards can be reused as 
appropriate. This can be important if multiple research 
groups would like to use the same RF front end or if the 
FPGA board is costly, such as when populated with an 



FIGURE 10 - TOYON EXP-BASED PROTOTYPE 
SOFTWARE DEFINED RADIO 


In order to prototype wireless transceiver designs, Toyon 
frequently leverages EXP -based development boards and 
associated daughtercards [14]. Figure 10 illustrates the 
general concept with a prototype 500 ksps BPSK/QPSK 
transceiver developed on a NASA Phase I SBIR effort. 
The design consists of an Avnet Virtex5-LX50 based 
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XilinxFPGA 



FIGURE 11 - SOFTWARE DEFINED RADIO ARCHITECTURE 


prototype development board and custom Toyon- 
designed RF front end. The EXP RF board contains all 
analog processing along with associated analog and 
digital data converters. 

The overall architecture for the prototype radio is shown 
in Figure 11. Here we see the SoC architecture in the 
form of a mixture of hardware-based baseband signal 
processing as well as microprocessor software control. 
For a typical design, all baseband processing will be 
performed in hardware with packet formatting and data 
handling performed in a microprocessor. This approach 
is meant to provide a compact and efficient solution that 
minimizes size, weight, and power. The additional 
benefit of the SoC approach is that additional peripherals, 
such as backend RS232, RS422, or Ethernet, interfaces 
can be incorporated within the same hardware and 
software design. 


XIII. FORWARD WORK: TRANSITIONAL LINK LAYER 

Although a high level 802. 16e system profile is identified 
in this report that supports the data flow needs of the 


EVA system, it requires that a base station be the router 
and arbitrator of all data flows and radio resources. This 
presents a fundamental limitation in the application of 
this technology in lunar surface EVAs. This 802. 16e 
system is capable of making very efficient use of the 
radio resources, support strict quality of service policies 
and efficient use of EVA power. However, the system 
would not be attractive for early sortie missions in which 
little or no surface infrastructure is available and the 
primary goal is surface exploration. At this time, this 
likely requires some innovation to enable point-to-point 
communications outside of the scope of what is offered 
by implementations of the 802. 16e ammendment and the 
existing system profiles. 

Therefore, alternative methods for supporting point-to- 
point communications are considered. Three approaches 
were evaluated. 

The first approach is to consider options for supporting 
point-to-point communications within the existing 
standard. The mesh capability in the standard is an 
optional portion of for which the commercial industry 
has not produced viable implementations. However, the 
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802. 16h License Exempt Working Group [15] is 
currently considering including such capability as an 
amendment to the standard. This capability does not map 
directly to NASA operational concepts and the draft 
amendments are far from being ratified. Therefore, this 
option will not be pursued further at this time. 

The second approach consists of supporting a mutli- 
mode and perhaps a reconfigurable radio within the EVA 
suit that has the ability to communicate utilizing a 
hierarchy of wireless protocols. In this scheme, the EVA 
radio may communicate with some defined infrastructure 
in one mode (e.g. an 802. 16e based system), and in a 
point-to-point fashion in another mode (e.g. in an 
802.1 lg ad hoc mode). This approach is feasible, 
however there is a clear desire to minimize the amount of 
discrete hardware, firmware, and software components 
required to be implemented as part of the EVA 
communication subsystem. Each functional component 
represents a hardware/firmware/software component that 
requires certification for man-rated space flight, equating 
to higher implementation cost. 

The third approach is to make use of the physical layer 
(antenna and RF subsystems) designed to be compatible 
with the 802. 16e system profile identified in this report. 
However, a custom link layer protocol would be 
designed specifically for point-to-point operations and to 
support the data flow priorities for Constellation systems. 
This approach has the benefits of utilizing a common RF 
and antenna subsystem in both the point-to-point and 
infrastructure modes, directly supporting Constellation 
Systems priority of network traffic at the link layer and 
easing the transition from lunar sortie missions to 
missions which rely on lunar surface infrastructure. 

Once the lunar surface infrastructure has been built for 
longer duration stays, an 802. 16e PMP system would 
ideally support local communications around lunar 
habitats, providing NASA systems, commercial systems, 
and potentially international partners a standard way of 
interoperating. However, even during lunar outpost 
missions, EVA radios must be able to transmit voice and 
limited suit data directly between two EVA crew 
members without reliance on other assets. EVA's use the 
buddy system where crews will always perform 
procedures on the lunar surface in close proximity to 
each other. 

As part of NASA’s Exploration Technology 
Development Program, a development activity is 
underway to prototype this custom link layer and modem 
as part of a proof-of-concept system. The custom link 


layer will make use of the Toyon modem to demonstrate 
the approach in 2009. 

The preliminary design is to use MAC frame formats 
already defined by the 802. 16e standard. Additionally, it 
will only utilize the modem as an OFDM transceiver, 
thereby not fully utilizing the OFDM A and S -OFDM A 
enhancements introduced in later amendments of the 
original 802.16-2004 standard. This straightforward use 
of the modem will simplify the initial implementation, 
meeting EVA’s data flow requirements without excessive 
functionality. The demo system will make use of the 
pilot-inserted tones necessary for channel estimation and 
equalization as well as the use of controllable cyclic 
prefix length of the OFDM symbols, thereby alleviating 
some concerns related to the effects of multipath 
interference. 

One assumption made by this implementation is that all 
lunar surface assets have a common timing reference. 

No attempt has been made as of yet to define the local 
clock stability or the frequency of the synchronization 
signal. However, the synchronization signal will be used 
both by the navigation subsystem as well as the 
communication subsystem. Prime candidates for the 
source of these synchronization signals (similar to the 
pulse per second signals obtainable from some GPS 
receivers) would be the Altair, Lunar Communications 
Tower, habitat, or even the Lunar Relay Satellites. 

Utilizing this common timing reference, a scalable 
TDMA approach is planned. All in-network lunar nodes 
(e.g. EVAs, Altair, LCT, Rover, etc.) have transmit 
opportunities within a given amount of time, defined here 
as an epoch. NASA has the luxury of very well defined, 
scripted scenarios in which the number of in-network 
radio devices is defined for each mission. Therefore, 
combined with a common timing reference, contention 
periods are not necessary for network entry. 
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Frequency 


Priority of multiple-access to the radio channel in a half- 
duplex sense may be governed by hardware address and 
transmit data queued. 

Figure 12 displays an example of a single epoch, in 
which two EVA astronauts, the Altair, and a Rover are 
part of the lunar surface radio network. The epoch length 
(time) will remained fixed, whereas the data bursts 
within each epoch may vary based upon the data queued 
for transmit within each node. 

Figure 13 displays an example of a single data burst. 

Each OFDM symbol within a data burst will be 
modulated with a single code rate/error correction code 
combination based strictly on the priority of data carried 
within that symbol. Radio control information will be 
sent within each burst that will notify each node within 
the network of queued traffic and the associated priority 
of that data for the transmitting node. When blockages 
occur and radio control information cannot be shared 
among all radio network participants, the nodes will 
default to a simplified epoch/burst configuration ensuring 
that high priority traffic is conveyed. 

The design of this transitional link layer is a work in 
progress and will evolve over the course of development. 
However, the three primary requirements associated with 
this development are to 1) satisfy EVA requirements, 2) 
keep the implementation simple, and 3) ensure an easy 
transition to operation within a fully-compliant 802. 16e 
network defined by the system profile presented within 
this report. 


n 


Similar to the modem design, this link layer logic will be 
prototyped on an FPGA utilizing a soft microprocessor 
core for algorithm execution as well as data formatting. 
Later versions of the prototype will aim to integrate all 
baseband and protocol processing on a single FPGA, 
with the goal of targeting a radiation tolerant 
implementation. 

XIV. CONCLUSIONS 

This study has identified a high level system profile of an 
802. 16e deployment (defined by the parameters in Table 
6) that meets the data flow requirements of the EVA 
system. However, this 802. 16e system is an 
infrastructure based system similar in operation to 
cellular phone networks. 

Lacking immediate infrastructure on the lunar surface, a 
network in which all radio resources are arbitrated by a 
central controller is not a viable solution. Therefore, an 
intermediate approach is to design a radio that has a 
migration path to interoperate with an 802. 16e based 
radio network, yet meet immediate requirements for 
initial sortie missions. 

This study also introduces a current work in progress, 
which couples the modem development of the Toyon 
Corporation (under a 2007 Phase II Small Business, 
Innovative Research contract), with a custom link layer 
that includes a primary goal of easing the transition to an 
infrastructure-based system. 


Guard Times 


Data Burst 



Time 


One Data Epoch 

FIGURE 12 - SINGLE EPOCH OF SURFACE 
WIRELESS NETWORK DATA BURSTS 


Design, development, and integration of the first 
prototype radio system will extend through September of 
2009. 



One EVA Data Burst (Time Slot) 


FIGURE 13 - SINGLE EVA DATA BURST 
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